What

If WhisperRecognizer::transcribe ever panics (a Rust panic inside the sherpa-rs binding — e.g. on unexpected output), the panic unwinds the transcription worker thread. The forwarder then sees the result channel disconnect and marks the session transcription-degraded — so a single bad chunk silently ends transcription for the entire rest of the meeting.

Fix

Wrap the ASR call in catch_unwind (catch_panic helper): a panicking chunk is logged and skipped, and the worker keeps processing subsequent audio. This mirrors Handy's documented "catch_unwind around the engine" practice. The happy path is byte-identical (Some(result)); only the panic path changes.

Verification (TDD)

• RED→GREEN: catch_panic tests (Some on success, None on panic).
• clippy --all-targets --all-features -- -D warnings ✅; full cargo test → 2 new tests pass, only the pre-existing model_archive_consts_tests (REPLACE_WITH_ placeholders) fail.

Notes

• Scope/KISS: a persistent panic (every chunk) still ends with no transcript (no degraded signal) — a rare-within-rare case; each panic is logged. A consecutive-panic counter or engine-rebuild was deliberately omitted as YAGNI for now.
• Merge order: touches process_completed_segments + adds #[cfg(test)] mod tests, so it will conflict with fix(transcription): persist real segment end times, not a fixed 1s span #4 and fix(transcription): resample from the real capture sample rate #6 in worker.rs — resolve by combining (they edit different parts of the same function/file).

⚠️ CI red on maintainer-only blockers (not this PR)

Uncommitted vendor/vc_redist.x64.exe + REPLACE_WITH_ SHA256/pubkey placeholders. Verified locally with a temp untracked vendor placeholder. Code-only, no new deps.